\section{Mock Objects}
Behaviour Driven Development practitioners frequently use objects which are simpler than the collaborating code, and provide the same interface but more predictable behaviour. They are called mocks because they mimic real objects for testing based on behaviour verification. To describe the idea of testing using mock objects, it will be contrasted with the common testing technique of code units.

\subsection{Regular Tests}
Let's imagine an example in which an order object is taken and filled from a~warehouse object. An order consists of one product and a~quantity, while a~warehouse holds inventories of different products. When an order fills itself from a~warehouse, there are two possible responses. If there is enough product in the warehouse to fill the order, the order becomes filled and the warehouse's amount of the product is reduced. If there is not enough product in the warehouse then the order is not filled. These two behaviours imply a~couple of unit tests:

\begin{lstlisting}[label=junit-test,caption=Example of regular tests in JUnit]
public class OrderStateTester extends TestCase {
    private static String TALISKER = "Talisker";
    private static String HIGHLAND_PARK = "Highland Park";
    private Warehouse warehouse = new WarehouseImpl();

    protected void setUp() throws Exception {
        warehouse.add(TALISKER, 50);
        warehouse.add(HIGHLAND_PARK, 25);
    }
    
    public void testOrderIsFilledIfEnoughInWarehouse() {
        Order order = new Order(TALISKER, 50);
        order.fill(warehouse);
        assertTrue(order.isFilled());
        assertEquals(0, warehouse.getInventory(TALISKER));
    }

    public void testOrderDoesNotRemoveIfNotEnough() {
        Order order = new Order(TALISKER, 51);
        order.fill(warehouse);
        assertFalse(order.isFilled());
        assertEquals(50, warehouse.getInventory(TALISKER));
    }
\end{lstlisting}

So for this test the primary object (Order) and one collaborator (Warehouse) are needed. The warehouse is required for two reasons -- to get the tested behaviour working at all and for verification. This style of testing uses state verification, which means checking correctness of the primary object and its collaborators after the specific method was called. Mock objects enable a~different approach to verification.

\subsection{Mock Tests}

Mock objects can be defined and used for testing in the following way: 

\begin{lstlisting}[label=jmock-test,caption=Example of mock tests in JMock]
public class OrderInteractionTester extends MockObjectTestCase {
    private static String TALISKER = "Talisker";

    public void testFillingRemovesInventoryIfInStock() {
        Order order = new Order(TALISKER, 50);
        Mock warehouseMock = new Mock(Warehouse.class);

        warehouseMock.expects(once()).method("hasInventory")
          .with(eq(TALISKER),eq(50))
          .will(returnValue(true));
        warehouseMock.expects(once()).method("remove")
          .with(eq(TALISKER), eq(50))
          .after("hasInventory");

        order.fill((Warehouse) warehouseMock.proxy());

        warehouseMock.verify();
        assertTrue(order.isFilled());
    }

    public void testFillingDoesNotRemoveIfNotEnoughInStock() {
        Order order = new Order(TALISKER, 51);    
        Mock warehouse = mock(Warehouse.class);
          
        warehouse.expects(once()).method("hasInventory")
          .withAnyArguments()
          .will(returnValue(false));

        order.fill((Warehouse) warehouse.proxy());

        assertFalse(order.isFilled());
    }
\end{lstlisting}

The key difference is the way of verification of the interaction between the order and the warehouse. With state verification it is done by asserts against the warehouse's state. Mocks use behaviour verification -- if the order made the correct calls on the warehouse. To achieve that, the mock is told what to expect during setup and asked to check itself during verification. Only the order is verified using asserts.

\subsection{The Difference Between Mocks and Stubs}

In those two styles of testing, the first case uses a~real warehouse object and the second case uses a~mock warehouse. Using mocks is one way to avoid a~real warehouse in the test, but there are other forms of unreal objects performing in the process of testing. A~generic term \textit{test double} describes any kind of such a~pretend object~\cite{Fowler2007}:

\begin{description}
\item[dummy] is passed around usually to fill parameter list and never used again,
\item[fake] is implemented in a~simple way and not suitable for production (e.g. in-memory database),
\item[stub] provides a~fixed result to calls made during the test,
\item[mock] has pre-programmed calls which it is expected to receive.
\end{description}

Of these kinds of doubles, only mocks insist upon behaviour verification, the other ones usually use state verification. Behaviour Driven Development takes the mockist approach -- introduces a~mock for any object with interesting behaviour instead of using real objects. 
